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Abstract 

'The  Future  Networks  section  of  CCl  division  uses  Mascot  HI  in  designing  parallel 
systems.  These  designs  are  then  implemented  in  the  Ada  programming  language.  A 
systematic  method  for  mapping  Mascot  designs  into  Ada  programs  has  been  devel¬ 
oped,  and  this  document  describes  the  main  characteristics  of  the  method.  In  most 
applications,  the  mapping  in  its  basic  form  is  entirely  adequate,  and  so  a  large  part  of 
the  document  is  spent  in  describing  this.  However,  certain  situations  present  problems 
which  can  only  be  solved  by  making  some  alterations.  Therefore  a  short  section  on 
these  problems  and  their  solutions  is  also  included. 

The  method  was  chosen  since  it  produces  Ada  programs  with  components  cor¬ 
responding  directly  to  the  Mascot  design.  This  was  considered  a  big  advantage  in 
producing  maintainable  and  clear  code.  Mascot  Templates  (both  algorithmic  and 
structural)  are  represented  as  generic  packages,  and  Mascot  components  are  instanti¬ 
ations  of  those  packages.  -  -  —  ,  -  /  ‘  : 
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1  Introduction 


Mascot  is  a  software  engineering  methodology  which  is  particularly  applicable  to  real¬ 
time  systems.  It  also  embraces  parts  of  the  software  life-cycle  (eg  testing)  which  other 
methodologies  do  not  reach.  These  two  features  have  contributed  to  Mascot’s  popularity 
and  wide  use. 

For  this  reason,  a  study  was  commissioned  by  the  Ministry  of  Defence  into  pcssible 
mappings  between  Mascot  III  and  the  Ada  programming  language  [3].  The  study  suggested 
nine  possible  ways  in  which  the  Mascot  design  philosophy  could  be  modelled  in  Ada.  This 
paper  describes  a  method  most  closely  related  to  method  seven  of  that  study.  The  method 
in  its  basic  form  falls  down  when  used  in  certain  systems,  and  so  some  possible  extensions 
and  alterations  have  also  been  suggested. 

The  mapping  does  not  proscribe  any  of  the  real-time  Ada  facilities,  but  it  promotes  a 
more  systematic  approach  to  their  use.  A  detailed  knowledge  of  the  basics  of  Mascot  HI 
is  assumed,  together  with  an  understanding  of  the  Ada  programming  language. 

It  is  hoped  that  this  document  will  achieve  two  aims.  First,  it  is  intended  as  a  manual 
for  people  trying  to  learn  the  method  for  the  first  time.  Therefore,  a  large  number  of 
examples  have  been  included  illustrating  various  points.  Secondly,  a  few  comments  have 
been  made  assessing  the  strengths  and  weaknesses  of  the  method. 

A  variety  of  experiments  using  the  method  were  performed  by  the  Future  Networks 
section  of  CCI  Division.  The  DEC  Ada  compiler  was  used  [2]  running  on  DEC’S  VMS 
Operating  System  for  all  the  experiments.  Some  very  simple  systems  were  implemented,  eg 
in  demonstrating  the  famous  Triple* example  described  in  the  Mascot  Handbook,  (see  [1]). 
The  DoD  Internet  Protocol  (4]  was  also  implemented  using  the  method,  to  demonstrate 
its  feasibility  in  large  systems. 
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2  The  Mapping  from  Ada  to  Mascot  III 

2.1  Overall  Strategy 

Each  Mascot  object  (IDA,  Pool,  Channel,  Activity,  Subsystem)  is  treated  as  an  Ada  pack¬ 
age.  Mascot  templates  are  generic  packages,  Mascot  instances  are  instantiations  of  those 
packages.  Each  package  is  separately  compiled  and  inserted  into  an  Ada  library.  This 
promotes  software  modularization  and  reusability. 

2.2  Mechanism  for  window  implementation 

A  Mascot  access  interface  consists  of  a  list  of  procedures.  Once  an  access  interface  has 
been  defined,  it  acts  in  the  same  way  as  a  type  declaration  in  a  programming  language. 
A  window  of  a  particular  access  interface  type  provides  the  procedures  defined  by  that 
interface. 

Each  window  is  an  ‘inner’  package  specification  within  the  generic  package  specification. 
Consider  the  simple  channel  below: 

ACCESS  INTERFACE  GET-INT; 

PROCEDURE  GET  (I  :  OUT  INTEGER); 

-  HOLDS  IF  THE  CHANNEL  IS  EMPTY 
PROCEDURE  CLEAR; 

-  EMPTIES  THE  CHANNEL 
END. 

ACCESS  INTERFACE  PUT-INT; 

PROCEDURE  PUT  (l  :  IN  INTEGER); 

-  HOLDS  IF  THE  CHANNEL  IS  FULL 
PROCEDURE  CLEAR; 

END. 

CHANNEL  SIMPLE-CHAN-TEMP; 

CONSTANT  MAX-CHAN-SIZE  :  POSITIVE; 

-  THE  MAXIMUM  NUMBER  OF  INTEGERS  WHICH 

-  CAN  BE  STORED  IN  THE  CHANNEL. 

PROVIDES  GW  .  GET-INT; 

PROVIDES  PW  .  PUT-INT; 

END. 


The  channel  possess  two  windows,  pw  and  gw,  one  of  type  put-int  and  the  other  of 
type  getjnt.  This  is  turned  into  Ada  as  follows: 


GENERIC 

max.chan.size  :  positive ; 
PACKAGE  simple. chan.tenp  IS 
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PACKAGE  gw  IS 

PROCEDURE  get  (i  :  OUT  integer); 
--  holds  if  the  channel  is  empty 
PROCEDURE  clear; 

--  empties  the  channel 
END; 

PACKAGE  pw  IS 

PROCEDURE  put  (i  :  in  integer) ; 
—  holds  if  the  channel  is  full 
PROCEDURE  clear; 

END; 

END  simple. chan.temp ; 


A  useful  naming  convention  is  to  use  template  names  as  generic  package  names,  and 
the  window  names  as  the  internal  package  names.  The  procedure  headings  are  copied 
directly  from  the  Mascot  access  interface. 

2.3  Mechanism  for  port  implementation 

A  port  of  a  particular  access  interface  type  can  call  any  of  the  procedures  defined  by  that 
interface.  A  port  and  a  window  can  only  be  connected  if  they  are  of  the  same  access 
interface  type.  A  Mascot  template  has  ports  which  are  not  yet  connected  to  windows. 
It  is  only  when  components  are  created  from  that  template  that  the  connection  between 
ports  and  windows  is  established. 

It  was  decided  that  the  generic  formal  procedures  of  a  package  were  the  best  method  of 
mapping  ports  to  Ada.  Each  access  interface  procedure  becomes  a  formal  parameter  of  the 
generic  package.  The  problem  of  identical  procedure  names  in  different  ports  is  avoided 
by  prefixing  each  procedure  name  with  its  port  name  and  an  underscore.  Consider  the 
following  activity; 


ACTIVITY  ACT-TEMP; 

REQUIRES  PUTP  :  PUT-JNT; 
REQUIRES  GETP  :  GET-1NT ; 

END. 


Such  an  activity  is  turned  into  Ada  as  follows: 

GENERIC 

WITH  PROCEDURE  putp.put  (1  :  IN  Integer) ; 
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WITH  PROCEDURE  putp.clear; 

WITH  PROCEDURE  getp.get  (1  :  OUT  integer) ; 

WITH  PROCEDURE  getp.clear; 

PACKAGE  act.temp  IS 
PRIVATE 

--  the  purpose  ol  this  pert  is  purely  sesthetic . 

--It  means  that  ports  can  be  referenced  by  the 
--  usual  Mascot  dot  notation  within  the  activity  body. 
PACKAGE  putp  IS 

PROCEDURE  put  (1  :  IS  integer)  RENAMES  putp.put; 
PROCEDURE  clear  RENAMES  putp.clear; 

END  putp; 

PACKAGE  getp  IS 

PROCEDURE  get  (i  :  OUT  Integer)  RENAMES  getp.get; 
PROCEDURE  clear  RENAMES  getp.clear; 

END  getp; 

END  act.temp; 

PACKAGE  BODY  act.temp  IS 

PROCEDURE  act.proc  IS 
BEGIN 

--  code  for  the  activity 

END; 

TASK  activity .task; 

TASK  BODY  activity.task  IS 
BEGIN 

act .pro c ; 

END; 

END  act.temp; 


The  private  part  of  the  package  can  be  used  to  convert  the  procedure  names  to  their 
original  form  for  use  in  the  package  body 

2.4  Connecting  ports  to  windows 

A  particular  port  is  connected  to  a  window  by  passing  the  window  procedures  as  actual 
parameters  when  instantiating  the  generic  package  which  contains  the  port.  As  a  simple 
example,  suppose  an  activity  generates  a  stream  of  integers  to  be  passed  to  a  second 
activity.  This  is  achieved  by  the  use  of  a  simple  channel  as  above,  and  the  Mascot  textual 
notation  is  outlined  as  follows: 

ACTIVITY  ACT-TEMPI; 
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REQUIRES  PP  :  PUT-INT; 

END. 

ACTIVITY  ACT -TEMP 2; 

REQUIRES  GP  :  GET-INT; 

END. 

SYSTEM  TEST; 

USES  SIMPLE -CHAN-TEMP,  ACT-TEMPI,  ACT-TEMP2; 
CHANNEL  INTEGER-CHAN  1  :  SIMPLE-CHAN-TEMP 
(MAX-CHAN-SIZE  =  100); 

ACTIVITY  A 1  :  ACT-TEMPI  (PP  =  INTEGER-CHAN  1  PW) ; 
ACTIVITY  A2  :  ACT-TEMP2  (GP  =  INTEGER-CHAN  1  .GW) ; 

END. 


The  above  is  turned  into  Ada  as  follows: 

GENERIC 

WITH  PROCEDURE  pp.put  (i  :  IN  integer); 

WITH  PROCEDURE  pp.clear; 

PACKAGE  act.templ  IS 
PRIVATE 

PACKAGE  pp  IS 

PROCEDURE  put  (i  :  IN  integer)  RENAMES  pp_put; 
PROCEDURE  clear  RENAMES  pp.clear; 

END  pp; 

END  act.templ ; 

PACKAGE  BODY  act.templ  IS 

PROCEDURE  act.proc  IS 
BEGIN 

--  code  lor  the  activity 

END; 

TASK  ectivity.taak; 

TASK  BODY  activity.task  IS 
BEGIN 

act.proc ; 

END; 

END  act.templ ; 
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GENERIC 

WITH  PROCEDURE  gp.get  (i  :  OUT  integer) ; 

WITH  PROCEDURE  gp.clear; 

PACKAGE  act_temp2  IS 
PRIVATE 

PACKAGE  gp  IS 

PROCEDURE  get  (i  :  OUT  integer)  RENAMES  gp.get 
PROCEDURE  clear  RENAMES  gp.clear; 

END  gp; 

END  act_teap2; 

PACKAGE  BODY  act_temp2  IS 

PROCEDURE  act.proc  IS 
BEGIN 

--  code  lor  the  activity 

END; 


TASK  activity. task; 

TASK  BODY  activity. task  IS 
BEGIN 

act.proc ; 

END; 

END  act.temp2; 


WITH  simple.chan.temp ,  act.terapl,  act_temp2; 

PROCEDURE  test  IS 

PACKAGE  integer.chanl  IS  NEW  simple.chan.teap  ( 
nax.chan.size  *>  100) ; 

PACKAGE  al  IS  NEW  act.templ  ( 

pp.put  «>  integer.chanl  pv. put, 
pp.clear  «>  integer.chanl .pv. clear) , 

PACKAGE  a2  IS  NEW  act_temp2  ( 

gp.get  *>  integer.chanl .gw. get. 
gp.clear  ■>  integer.chanl . gw . clear) ; 


BEGIN 

null; 

END; 
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3.5  Subsystems 

Subsystems  are  a  new  and  powerful  idea  introduced  in  Mascot  III.  They  enable  complex 
systems  to  be  broken  down  into  more  manageable  parts,  while  hiding  the  clutter  of  small 
details.  The  ports  of  a  subsystem  are  connected  to  the  ports  of  internal  subsystems,  or 
activities.  Likewise  with  windows. 

A  simple  example  is  the  best  way  to  illustrate  how  to  write  a  subsystem.  The  subsystem 
possesses  one  port  and  one  window.  The  textual  notation  is  as  follows: 


ACTIVITY  DUP-TEMP; 

REQUIRES  GP  :  GET-tNT; 
REQUIRES  PP  :  PUT-1NT; 

END. 

SUBSYSTEM  SIMPLE-SUB-TEMP; 
REQUIRES  GP  :  GET-1NT; 
PROVIDES  GW  :  GET-1NT ; 

USES  SIMPLE-CHAN-TEMP,  DUP-TEMP; 

CHANNEL  CH  :  SIMPLE-CHAN-TEMP 
(MAX-CHAN-SIZE  =  100); 
ACTIVITY  DUP  :  DUP-TEMP  ( 

PP  =  CH.PW, 

GP  =GP); 

GW  =  CH  .GW; 

END. 


The  Ada  for  the  above  is: 


GENERIC 

--  the  port  declaration 

WITH  PROCEDURE  gp.get  (i  :  OUT  integer) ; 

WITH  PROCEDURE  gp .clear; 

PACKAGE  aiBple.sub.tenp  IS 

--  the  window  declaration 
PACKAGE  gw  IS 

PROCEDURE  get  (i  :  OUT  integer); 

PROCEDURE  clear; 

END; 

PRIVATE 

--  the  port  renaaing 
PACKAGE  gp  IS 

PROCEDURE  get  (1  :  OUT  Integer)  RENAMES  gp.get; 
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PROCEDURE  clear  RENAMES  gp.clear; 

END  gp; 

END  simple.sub.temp; 

WITH  simple. chan. temp ,  dup.temp; 

PACKAGE  BODY  simple. eub.temp  IS 

PACKAGE  ch  IS  NEW  simple .chan.teap  (max.chan.size  ■>  100) ; 
PACKAGE  dup  IS  NEW  act.templ  C 
pp.put  ■>  ch.pw.put, 
pp.clear  ■>  ch.pw. clear, 
gp.get  ■>  gp ■ get . 
gp.clear  •>  gp.clear); 

PACKAGE  BODY  gw  IS 

PROCEDURE  get  (i  :  OUT  integer)  IS 
BEGIN 

ch.get  (i) ; 

END; 

PROCEDURE  clear  IS 
BEGIN 

ch. clear; 

END; 

END; 

END  simple.sub.temp ; 


2.6  Writing  the  code  for  Mascot  objects 

The  most  difficult  part  of  defining  the  mapping  from  Mascot  to  Ada  is  the  code-structure 
of  primitive  objects.  There  is  no  prescriptive  method  of  generating  the  code,  but  it  is  left 
to  the  judgment  of  the  implementor.  The  following  paragraphs  are  intended  as  guidelines. 

2.6.1  The  code  for  activities 

As  a  general  principle  it  has  been  found  that  activities  are  best  implemented  as  single 
tasks.  In  order  that  the  possibility  of  deadlock  is  minimized,  activity  tasks  should  have 
no  entries.  Rather,  all  synchronization  should  take  place  inside  the  IDAs,  in  keeping  with 
the  philosophy  of  Mascot. 

For  a  number  of  reasons,  waiting  for  events  by  continuous  polling  is  bad  programming 
practice.  Therefore,  activities  should  be  designed  to  avoid  pol’ing  wherever  possible.  (The 
Mascot  design  can  often  indicate  activities  which  are  in  danger  of  needing  to  poll:  the 
arrow-heads  on  paths  indicate  which  way  the  data  is  flowing.  Therefore,  if  more  than  one 
arrow-head  converges  on  an  activity,  it  may  be  that  the  activity  will  have  to  poll  those 
paths  for  data.)  There  are  two  possible  ways  to  avoid  having  to  poll.  With  careful  design, 
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it  may  be  possible  to  redesign  the  system  such  that  the  two  data  Bows  can  be  converged 
before  reaching  the  activity.  Alternatively,  the  system  can  be  treated  as  a  Finite-State 
Machine.  In  this  way  the  order  in  which  the  data  will  arrive  down  the  multiple  paths  is 
known  in  advance.  Thus  polling  is  not  required. 

2.6.2  The  code  for  IDAs 

IDAs  can  be  coded  in  a  variety  of  ways: 

•  Most  Ada  implementations  allocate  a  separate  stack  for  each  task.  When  procedures 
are  activated,  space  for  all  local  variables  is  allocated  on  this  stack.  Thus  it  is  possible 
for  two  tasks  to  execute  a  common  procedure  concurrently  provided  the  procedure 
does  not  update  a  non-dynamic  variable,  (i.e.  one  which  is  not  created  at  execution¬ 
time  on  the  stack).  If  an  IDA  has  no  internal  variables  which  are  changed  by  access 
procedures,  it  will  need  no  protection  mechanism.  This  type  of  IDA  is  typically  used 
to  initialize  read-only  variables  used  by  more  than  one  activity. 

•  Most  IDAs  have  internal  variables  or  state  information  which  is  updated  by  the 
access  procedures.  In  these  IDAs,  concurrent  access  must  be  prevented.  This  can  be 
achieved  in  a  variety  of  ways: 

-  Each  variable  may  have  its  own  guard.  Ada  tasks  can  be  written  which  imple¬ 
ment  semaphores  for  this  purpose.  If  more  than  one  process  accesses  a  variable, 
the  VMS  lock  management  services  are  useful. 

-  The  IDA  as  a  whole  can  be  protected.  Although  this  is  not  as  efficient  as  the 
previous  method,  the  code  is  much  simpler  to  write  and  debug.  It  is  suggested 
that  this  method  be  used  in  preference  to  the  above,  except  where  speed  is 
absolutely  essential. 

-  The  most  elegant  solution  is  to  encapsulate  the  whole  IDA  as  a  task.  Each  access 
procedure  becomes  an  entry  to  the  task.  The  great  strength  of  this  method  is 
that  the  rich  set  of  Ada  rendezvous  constructs  can  be  used  (eg  conditional 
or  timed  entry  calls).  Access  interface  procedures  are  made  very  much  more 
flexible  if  for  example,  a  time-out  parameter  can  be  supplied.  This  produces 
very  efficient  code  in  which  activities  are  automatically  suspended  until  re¬ 
scheduled.  An  example  of  this  can  be  found  in  the  channel  template,  (see 
below). 

2.7  Some  examples 
2.7.1  Two  activities 

The  first  activity  generates  a  stream  of  characters.  It  puts  these  characters  to  a  port. 
GENERIC 

HTH  PROCEDURE  pp.put  (ch  :  IN  character: 
wait.on.full  :  boolean  :•  true); 

WITH  PROCEDURE  pp.clear; 
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PACKAGE  gen.data.temp  IS 
PRIVATE 

PACKAGE  pp  IS 

PROCEDURE  put  (ch  :  IN  character; 

wait.on.iull  ;  boolean  ;*  true)  RENAMES  pp.put; 
PROCEDURE  clear  RENAMES  pp.clear; 

END  pp; 

END  gen.data.tenp; 

PACKAGE  BODY  gen.data.temp  IS 
PROCEDURE  task.code  IS 
BEGIN 
LOOP 

FOR  i  IN  ’A’ . . ’ Z ’  LOOP 
PP • put  (i) ; 

END  LOOP; 

END  LOOP; 

END  task.code; 

TASK  activity.task; 

TASK  BODY  activity .task  IS 
BEGIN 

task.code ; 

END  activity_taak; 

END  gen.data.temp; 


The  second  activity  reads  characters  from  a  port  and  prints  them  out. 

GENERIC 

WITH  PROCEDURE  gp.get  (eh  :  OUT  character) ; 

WITH  PROCEDURE  gp.clear; 

PACKAGE  print.data.temp  IS 
PRIVATE 

PACKAGE  gp  IS 

PROCEDURE  get  (ch  :  OUT  character)  RENAMES  gp.get; 
PROCEDURE  clear  RENAMES  gp.clear; 

END  gp; 

END  print.data.temp; 

WITH  text.io; 

PACKAGE  BODY  print.data.temp  IS 

PROCEDURE  taak.code  IS 
eh  :  character; 
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BEGIN 

LOOP 

gp  get  (ch); 
text.ioput  (ch); 
text.io . new. line ; 
END  LOOP; 

END  task.code; 

TASK  activity.task; 

TASK  BODY  activity .task  IS 
BEGIN 

taak.code; 

END  activity.taak; 

END  print .data.temp; 


2.7.2  A  channel 

The  following  channel  has  two  windows.  One  of  type  put -int  and  the  other  OF  type  get  jnt. 
GENERIC 

type  elem.type  IS  PRIVATE; 
max.chan.size  :  positive; 

PACKAGE  gen.chan.temp  IS 
PACKAGE  gw  IS 

PROCEDURE  get  (e  :  OUT  elem.type) ; 

--  holds  if  the  channel  IS  empty 
PROCEDURE  clear; 

--  empties  the  channel 

END; 

PACKAGE  pw  IS 

PROCEDURE  put  ( 

e  :  IN  elem.type ; 
wait.on.full  ;  boolean  :■  true); 

--  holds  if  the  channel  is  lull 
PROCEDURE  clear; 

END; 

END  gen. chan. temp ; 


PACKAGE  BODY  gen.chan.temp  IS 
TASK  ida.task  IS 

ENTRY  get.entry  (e  :  OUT  elem.type); 
ENTRY  put.entry  (e  :  IN  elem.type) ; 
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ENTRY  clear .entry; 

END  i da. task; 

TASK  BODY  ida.taak  IS 

buffer  :  ARRAY  Cl . .max.ehan.iize)  OF  elem.type; 
next.read.  next .written  :  integer  :•  1; 
current.aize  :  integer  :*  0; 

PROCEDURE  get  (e  :  OUT  elem.type)  IS 
BEGIN 

e  :•  buffer  (next.read); 

next.read  :«  (next.read  mod  max.ehan.iize)  +  1; 
current.aize  :»  eurrent.size  -  1; 

END; 

PROCEDURE  put  (e  :  IN  elem.type)  IS 
BEGIN 

buffer  (next.written)  :■  e; 

next.written  :»  (next.written  mod  max.chan.aize)  +  1 
current.aize  :«  current.aize  +  1; 

END; 

PROCEDURE  clear  IS 
BEGIN 

current.aize  :«  0; 
next.written  . ■  next.read; 

END; 

BEGIN 

LOOP 

SELECT 

WHEN  current. 8ize  /»  0  ■> 

ACCEPT  get. entry  (e  :  OUT  elem.type)  DO 
get  (e); 

END; 

OR 

WHEN  current.aize  <  integer  (max.chan.aize)  •> 
ACCEPT  put.entry  (e  :  IN  elem.type)  DO 
put  (e) ; 

END; 

OR 

ACCEPT  clear. entry  DO 
clear; 

END; 

END  SELECT; 
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END  LOOP; 
END  Ida. task; 


PACKAGE  BODY  gw  IS 

PROCEDURE  get  (e  :  OUT  elen.type)  IS 
BEGIN 

ida.taak . get.entry  (e); 

END; 

PROCEDURE  clear  IS 
BEGIN 

ida.taak . c lear .entry ; 

END; 

END; 

PACKAGE  BODY  pw  IS 
PROCEDURE  put  ( 

e  :  IN  elem.type; 

wait.on.full  :  boolean  :•  true)  IS 
BEGIN 

IF  wait.on.Iull  THEN 

ida.task. put .entry  (e) ; 

ELSE 

SELECT 

ida_task.put_entry  (e); 

ELSE 

null; 

END  SELECT; 

END  IF; 

END; 

PROCEDURE  clear  IS 
BEGIN 

ida.task . c lear.entry ; 

END; 

END; 


2.7.3  A  simple  system 

The  next  example  demonstrates  how  all  the  above  can  be  combined  into  a  real  system. 

WITH  gen.chan.tenp,  print. data.temp ,  gen.data.temp ; 

PROCEDURE  test  IS 
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PACKAGE  chi  IS  NEW  gen.chan.temp  C 
elem.type  »>  character, 
max.chan.size  *>  17); 


PACKAGE  gen.data  IS  NEW  gen. data. temp 
(pp.put  ■>  chi .pw .put . 
pp.clear  *>  chi  pw. clear) ; 

PACKAGE  print.data  IS  NEW  print.data.temp 
(gP-g**  _>  chi . gw  get , 
gp.clear  »>  chi- gw. clear); 


BEGIN 

null; 

END; 


2.7.4  A  simple  subsystem 

Thi*  examole  is  a  simple  duplex  subsystem.  The  subsystem  has  one  window  of  type  put 
Ld  two  windows  of  type  get.  Everything  inserted  into  the  put  window  >s  duphcated  m 

both  get  windows: 


GENERIC 

type  elem.type  IS  PRIVATE; 
max.chan.size  :  positive; 
PACKAGE  duplex.temp  IS 


PACKAGE  gwl  IS 

PROCEDURE  get  (e  :  OUT  elem.type) ; 
PROCEDURE  clear; 

END; 


PACKAGE  gw2  IS 

PROCEDURE  get  (e  :  OUT  elem_type); 
PROCEDURE  clear; 

END; 


PACKAGE  pw  IS 

PROCEDURE  put  ( 

•  ;  IN  elem.type; 
wait_on_lull  :  boolean  :■  true); 
PROCEDURE  clear; 

END; 

END  dnplex.temp; 


PACKAGE  BODY  duplex. temp  IS 

PACKAGE  eh  IS  NEW  gen_chan_temp( 
elem.type  *>  elem.type, 
max.chan.aize  *>  Bax.ehan.aize) ; 
PACKAGE  chi  IS  NEW  gen_eha»_temp( 

•  len.type  «>  elem.type, 

■ax.chan.aize  “>  Bax.ehan.aize) ; 
PACKAGE  eh2  IS  NEW  gen.ehan.tempC 
•lem.type  «>  elem_type, 
aax.chan.slze  “>  max.chan.aize) . 
PACKAGE  dup.data  IS  NEW  dup.data.temp 
(gp.get  *>  eh. gw. get, 
gp.clear  ■>  eh. gw. clear, 
ppl.put  ->  ehl.pw.put, 
ppl.clear  ■>  ehl . pw. clear , 
pp2_put  «>  eh2.pw.put. 
pp2_clear  «>  ch2.pw . clear) ; 

PACKAGE  BODY  gwl  IS 

PROCEDURE  get  (e  :  OUT  elem.type)  IS 

BEGIN 

chi. gw. get  (e); 

END, 

PROCEDURE  dear  IS 
BEGIN 

chi  gw. clear; 

END; 

END; 

PACKAGE  BODY  gw2  IS 

PROCEDURE  get  (e  ;  OUT  elem.type)  IS 

BEGIN 

eh2.gw.get  (e); 

END; 

PROCEDURE  clear  IS 
BEGIN 

ch2. gw. clear; 

END; 

END; 

PACKAGE  BODY  pw  IS 
PROCEDURE  put  ( 

e  ;  IN  elem.type; 


T 


wait.on.full  :  boolean  :■  true)  IS 
BEGIN 

eh.pw.put  (e,  wait.on.Iull) ; 

END; 

PROCEDURE  clear  IS 
BEGIN 

eh.pw. clear; 

END; 

END; 

END; 
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3  Possible  Enhancements  to  the  Mapping 

A  number  of  experiments  were  conducted  in  building  real  systems  using  the  method.  The 
experiments  varied  in  sire  from  simple  two-activity  systems  to  a  complete  implementation 
of  the  Internet  Protocol.  The  following  weaknesses  were  found  in  the  basic  method: 

•  Cyclic  dependency  problems. 

•  Calling  unelaborated  packages. 

•  Termination  difficulties. 

•  Recompilation  overheads. 

•  Shared  data. 

3.1  Cyclic  dependancy  problems 

Ports  are  connected  to  windows  by  associating  actual  procedures  with  generic  formal 
procedures.  This  means  that  windows  must  be  declared  before  the  ports  which  connect 
to  them.  This  is  impossible  to  do,  however,  in  a  system  with  cyclic  port  to  window 
dependancies. 

If  this  problem  arises,  a  slight  alteration  to  the  method  has  to  be  made.  At  the 
beginning  of  each  structural  unit  (subsystem  or  system),  procedure  /tubs  are  declared  for 
all  window  procedures.  Following  this,  the  objects  making  up  that  unit  can  be  declared  in 
any  order.  Ports  of  each  object  are  tied  to  the  stub  procedures.  After  all  the  objects  have 
been  declared,  the  stub  bodies  are  elaborated  Each  consists  of  a  call  to  the  appropriate 
window  procedure.  It  may  seem  that  this  results  in  an  inefficiency,  since  each  access 
procedure  results  in  two  subprogram  activations,  with  all  the  stack  initialisation  overheads 
being  duplicated.  However,  the  Ada  inline  pragma  can  be  used  to  overcome  this  problem, 
if  speed  is  critical  in  the  system. 

3.2  Calling  unelaborated  packages 

The  second  problem  may  come  about  as  result  of  the  solution  to  the  first  problem.  When 
packages  are  elaborated,  suiy  tasks  contained  in  the  bodies  are  activated  immediately.  As 
a  result,  an  activity  may  call  an  access  procedure  which  is  in  an  unelaborated  unit.  This 
results  in  a  PROGRAM— ERROR  exception  being  raised  in  the  activity.  This  problem 
can  be  solved  by  including  a  special  start  procedure  as  a  formal  parameter  of  all  activities 
and  subsystems  containing  active  elements.  The  first  thing  which  each  activity  does  is  to 
call  this  procedure.  At  the  system  level,  the  procedure  start  is  declared.  It  consists  of  a 
call  to  a  simple  semaphore  which  is  released  by  the  activation  of  the  main  program: 


procedure  eyetea  is 


TASK  semaphore  IS 
ENTRY  relates ; 
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ENTRY  start; 

END; 

TASK  BODY  semaphore  IS 
BEGIN 

ACCEPT  release; 

LOOP 

ACCEPT  start ; 

END  LOOP; 

END; 

PROCEDURE  start  IS 
BEGIN 

semaphore . start ; 

END; 

PACKAGE  aubsysl  IS  NEW  subsysl.temp  ( 
start  »>  start, 

--  other  ports 

); 

PACKAGE  eubsys2  IS  NEW  subsys2_temp  ( 
start  *>  start, 

--  other  ports 

); 


BEGIN 

semaphore .release ; 

END; 


This  causes  all  activities  to  ‘hang’  until  all  the  packages  have  been  elaborated. 

NB  this  corresponds  to  the  two-stage  process  described  in  the  Mascot  111  handbook. 
Initialiaation  consists  of  the  elaboration  of  each  package,  and  itarting  consists  of  a  trigger 
from  the  main  program.  (See  Section  4.6  of  the  Mascot  handbook). 

3.3  Termination  difficulties 

When  an  exception  occurs  in  an  Ada  task,  it  causes  the  task  to  terminate,  (unless  it  is 
handled  with  an  exception  handler).  All  other  tasks  continue  executing  normally.  This 
produces  a  problem  in  situations  when  it  would  be  preferable  to  abort  the  complete  system. 
In  tasks  which  declare  entries,  the  terminate  alternative  PROVIDES  a  means  of  aborting 
the  task.  However,  activities  should  possess  no  entries  if  they  have  b-.en  properly  mapped 
into  Ada.  Therefore  another  method  must  be  found  to  cause  them  to  terminate.  As  yet 
no  satisfactory  solution  has  been  found  for  this  problem.  One  possible  method  would 
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be  a  special  abort  procedure  possessed  by  all  objects.  The  outermost  level  of  each  task 
could  then  handle  all  exceptions  by  calling  the  abort  procedure  of  all  other  objects,  and 
then  re-raising  the  exception.  This  has  not  been  exhaustively  investigated  at  the  time  of 
writing. 

3.4  Recompilation  overheads 

The  instantiation  of  generic  units  is  an  extremely  slow  process  in  most  compilers.  It  is 
usually  achieved  by  a  macro-substitution  of  the  generic  entities  with  their  equivalents  and 
compiling  the  resulting  source  code.  For  large  subsystems,  this  can  result  in  a  considerable 
amount  of  recompilation.  This  problem  has  not  been  looked  at  seriously  since  it  is  regarded 
as  a  compiler  shortcoming  rather  than  a  weakness  in  the  mapping. 

3.5  Shared  data 

The  method  makes  a  distinction  between  two  types  of  package.  There  are  packages  repre¬ 
senting  Mascot  objects,  and  packages  which  declare  common  procedures,  type  definitions, 
constants  etc.  which  are  used  by  those  packages.  However,  it  is  possible  to  declare  share¬ 
able  data  in  the  second  type  of  package,  bypassing  the  whole  Mascot  method  of  protecting 
data.  Severe  errors  may  result  if  data  is  concurrently  written  by  more  than  one  activity. 
This  type  of  data  may  be  declared  in  the  body  of  such  packages,  and  so  may  not  easily 
be  spotted,  but  can  still  be  concurrently  accessed  by  more  than  one  activity.  Some  of  the 
predefined  packages  must  be  protected  from  this  type  of  access.  The  package  tezt  io  is  a 
case  in  point.  It  updates  the  cursor  position  when  procedure  put  is  called,  and  this  may 
result  in  undesired  effects  if  it  is  called  concurrently. 

The  solution  to  this  problem  is  to  encapsulate  these  packages  in  an  IDA.  The  IDA 
version  contains  all  the  same  procedure  declarations  as  the  original  package.  (Note  that 
types  and  constants  need  not  be  redeciared).  The  body  of  each  procedure  consists  of 
setting  a  semaphore,  calling  the  original  procedure,  and  releasing  the  semaphore. 

4  Conclusions 

The  method  has  been  used  with  good  success  in  a  wide  variety  of  applications.  There  have 
been  a  number  of  benefits  which  have  resulted  from  its  use: 

•  Software  is  better  structured  and  easier  to  maintain.  (‘Raw’  Ada  tends  to  be  com¬ 
pletely  ad  hoc  in  its  use  of  concurrency  features.) 

•  The  Mascot  idea  of  active  and  passive  design  elements  makes  deadlock  situations 
much  easier  to  detect. 

•  A  large  library  of  reusable  templates  can  be  built  up,  producing  much  more  reliable 
and  maintainable  programs. 

The  main  disadvantage  of  the  method  is  the  amount  of  time  taken  to  manually  code 
object  templates.  Each  access  interface  procedure  has  to  be  duplicated  four  or  five  times 
in  order  to  link  a  port  to  a  window.  For  an  access  interface  of  ten  or  more  procedures,  this 
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can  be  an  extremely  time-consuming  process.  An  automatic  method  of  generating  code 
would  be  invaluable  in  developing  large  systems. 

Another  disadvantage  is  the  time  taken  to  compile  generic  packages.  The  DEC  Ada 
Compiler,  for  example,  recompiles  all  generics  at  each  instantiation.  However,  with  faster 
hardware  and  better  compiler  techniques,  this  problem  will  gradually  diminish. 
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